Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm trying to compose a one-line command that recursively searches a directory for all files ending in <digit>.in, and then runs the man command on each file found, piping the output from each man command into a separate file on my Desktop.
The result should be a series of files on my Desktop e.g. "ext2ed", "e2fsck" etc.
The problem I'm encountering is that the files are not generated because {} expands to the complete filename, including path, thus producing the following errors:
Code:
find: ‘man ./ext2ed.8.in > ~/Desktop/./ext2ed.8.in’: No such file or directory
find: ‘man ./e2fsck.8.in > ~/Desktop/./e2fsck.8.in’: No such file or directory
Is there any way I can have my second {} expansion produce the path-less filename, or will I have to write and run a script to achieve my goal?
This by itself will not be enough as it will still have the extensions (man pages are USUALLY something like "zsh.1.gz", and doing "man zsh.1.gz" won't work, but "man zsh" will work.
Also note that some man pages (like "stat") have multiple entries, one in any relavent section, thus "man stat" will get you the page for the stat command, but "man 2 stat" will get you the information on the system call. The file name is different too: "stat.2.gz".
The files are "subject"."section"."compression" usually... Sometimes you will find man pages without the compression, but instead the "man" extension.
And that variation requires the filename to be processed in more than the simple approach. I think you will have to parse the file name to handle the section numbers as well.
BTW, the problem has been addressed before: http://linux.die.net/man/1/bookman
UNFORTUNATELY, my google fu didn't find where the source to the utility was.
If you find it, please post where it is... I (and others) would find it useful as well. It is rather hard to refer to a man page for configuration information... when the computer won't work well enough to access man pages.
I think you need a small script to parse found files names, I don't think "man ext2ed.8.in" would return something usefull on your system, rather it would be "man 8 ext2ed", no?
But I still think this is not going to work as expected
You were right.
Code:
ext2ed.8.infind: ‘man ./ext2ed.8.in > ~/Desktop/ ./ext2ed.8.in’: No such file or directory
e2fsck.8.infind: ‘man ./e2fsck.8.in > ~/Desktop/ ./e2fsck.8.in’: No such file or directory
This by itself will not be enough as it will still have the extensions (man pages are USUALLY something like "zsh.1.gz", and doing "man zsh.1.gz" won't work, but "man zsh" will work.
Also note that some man pages (like "stat") have multiple entries, one in any relavent section, thus "man stat" will get you the page for the stat command, but "man 2 stat" will get you the information on the system call. The file name is different too: "stat.2.gz".
The files are "subject"."section"."compression" usually... Sometimes you will find man pages without the compression, but instead the "man" extension.
And that variation requires the filename to be processed in more than the simple approach. I think you will have to parse the file name to handle the section numbers as well.
BTW, the problem has been addressed before: http://linux.die.net/man/1/bookman
UNFORTUNATELY, my google fu didn't find where the source to the utility was.
If you find it, please post where it is... I (and others) would find it useful as well. It is rather hard to refer to a man page for configuration information... when the computer won't work well enough to access man pages.
I have no problems with the filenames or man structure.
I think you need a small script to parse found files names, I don't think "man ext2ed.8.in" would return something usefull on your system, rather it would be "man 8 ext2ed", no?
The files are all in a directory structure containing the source code of e2fsprogs. The ".in" section reflects the fact that the files are pre-processed to insert some e2fsprogs-specific values (version number etc.) but I don't care about those.
Running
Code:
man ./ext2ed.8.in
produces a good man page. The only problem is that I need the second {} in my one-liner to return the file basename, not the whole path.
I think that jpollard is on to it with his suggestion of using the basename command, it's just a question of finding the right way to incorporate it in the one-liner.
One of the things done to the .in file is to modify configuration pathnames, library references, header references. There can even be differences depending on architecture the resulting software is installed on.
So you are missing a lot more than just the version number.
One of the things done to the .in file is to modify configuration pathnames, library references, header references. There can even be differences depending on architecture the resulting software is installed on.
So you are missing a lot more than just the version number.
I appreciate that, thanks, but really it is not important to me.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.